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(57) Abstract: The present invention proposes a communication network, said network comprising at least an application server 
means (APSE), a subscriber information register means (HSS), a call state control functional entity (CSCF), and a service portal 
(SP), wherein said application server means (APSE) is connected to said service portal (SP) and to said call state control functional 
entity (CSCF), said service portal is further connected to said home subscriber server means (HSS), and said subscriber information 
register means (HSS) is further connected to said call state control functional entity (CSCF). In connection with the proposed network 
architecture, the present invention also proposes methods for handling service scripts within the network with regard to creation and 
storage of service scripts, provisioning the service scripts for a user, distribution of the scripts in the network and execution of the 
scripts during call processing. 
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1 

TITLE OF THE INVENTION 

ARCHITECTURE FOR SERVICE SCRIPT EXECUTION AND MANAGEMENT 

5 

FIELD OF THE INVENTION 

The present invention concerns the field of IP telephony, 
i.e. telephony using the Internet iProtocol, and more 
10 particularly, is related to the usage of service scripts 
for controlling the call handling in a communication 
network operated, e.g. according to the internet protocol, 
and hereinafter also referred to as all-IP network. 

15 BACKGROUND OF THE INVENTION 

Hitherto, in a coitmiunication environment, value added 
services have centrally been implemented in a so-called 
Service Control Point (SCP) using intelligent network (IN) . 
20 Thus, service creation, management and execution has been 
centralized to the service control point SCP as a 
specialized functional entity. 

Service scripts provide a means to create and manage value 
25 added services in a centralized fashion (which is the 

benefit of an intelligent network) but distribute fully the 
service execution (which is a bottleneck of an intelligent 
network) . 

30 Service logic is defined with a script which can be moved 
between functional elements (FE) in a all-IP network "and 
which is executed in a suitable FE- 

Usable script languages can be, for example, GPL (Call 
35 Processing Language), SIP Servlets (SIP: Session Initiation 
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Protocol) representing executable instructions which handle 
SIP messages, or CGI (Conunon Gateway Interface) . However, 
although the present description refers to the above 
mentioned script languages, this is only for explanatory 
5 purposes and by no way limiting the applicability of the 
present invention to those script languages. Of course 
other script languages can be used in connection with the 
present invention. 

10 More precisely, referring to the Call Processing Language 

(CPL) , CPL is related to IP telephony, IP telephony enables 
calls and multimedia sessions such as simultaneous videa 
and audio calls to be set-up across IP networks. The CPL is 
intended to be a simple lightweight, efficient and easy to 

15 implement language for IP telephony supplementary service 
creation. It is intended to be independent of operating 
systems or signaling protocols such as SIP or H.323. CPL is 
intended particularly for end-user-defined supplementary 
service creation. The aim is that these scripts can be 

20 defined and provisioned quickly at the spot. Because of 

this, For the creation of CPL scripts various user friendly 
techniques such as graphical symbolic editors have been 
envisioned. 

25 CPL is not related to the creation of end-to-end 

teleservices such as voice or video calls. Instead it is 
rather used for supplementary service creation. By a 
supplementary service is meant a service that is separately 
defined to alter in the network the treatment of calls 

30 involving certain basic end-to-end services i.e. 
teleservices and bearer services. For example, 
supplementary services can affect call routing (e.g. 
redirect them to different addresses) or screen incoming or 
outgoing calls. 



35 
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The CPL language scripts are distributed to the IP 
telephony servers participating to the handling of the 
calls that need to be affected using these supplementary 
services. The scripts are inserted to these servers by the 
5 IP telephony network management system, end-user or 

administrators. There can be several CPL script instances 
participating to the handling of a given call. The 
individual script instances are triggered and executed on 
signalling events conforming to predefined criteria such as 
10 caller or callee identification. For example, when there is 
an incoming call to a subscriber who has defined an 
incoming call screening script^ the script is executed 
because the callee identification matches. 

.15 In general, scripts (service scripts) provide an efficient, 
portable and powerful tool for executing control 
instructions in a distributed network. Scripts are for 
example used in Internet web pages to create different kind 
of effects for users. A script is transferred (downloaded) 

20 from a web server to the local computer and executed there. 

Furthermore, up to now the architecture has been open, both 
in standardization and implementation. However, in order to 
use scripts for service implementation, some architecture 
25 and arrangement must be provided. 

Moreover, using CPL scripts in connection with SIP invite 
methods means to put call processing language (CPL) scripts 
into SIP invite methods. These can provide a service 
30 execution in proxy nodes as specified by the user in an IN 
network type. Hitherto, however, a SIP client (terminal) 
added the script to the invite method^ thereby resulting in 
an increased signaling amount. 

35 SUMMARY OF THE INVENTION 
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It is an object of the present invention to provide an 
architecture and handling scenario for using service 
scripts within an all-IP communication network. 

5 

Still further, it is an object of the present invention to 
improve the usage of, for example, CPL scripts in 
connection with SIP invite methods . 

10 Also, the present invention aims to provide 

• a solution for a functional work split in all-IP 
architecture for network and user originated service script 
creation, distribution and execution, 

• improved concepts on how scripts can be created and what 
15 parameters should be taken into account, 

• improved concepts on how script execution can be managed 
so that network integrity and performance is not in danger, 

• improved concepts on how scripts are armed and executed 
in the network and what data is needed for these purposes, 

20 • improved concepts for script storage and delivery across 
the network, including suggestions for required parameters, 

• improved concepts for separating the data and logic of 
the script. 

25 In addition, it is an object of the present invention to 
prevent misbehaving users from attacking the computers of 
an all-IP communication network over the network when using 
service scripts within said network. 

30 According to the present invention, the above objects and 
aims are, for example, fulfilled by 

a communication network, said network comprising at least 
an application server means, a subscriber information 
register means, a call state control functional entity, and 
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a service portal, wherein said application server means is 
connected to said service portal and to said call state 
control functional entity, said service portal is further 
connected to said subscriber information register means, 
5 and said subscriber information register means is further 
connected to said call state control functional entity, 
wherein said application server means comprises - 
a script management functional entity, and said script 
management functional entity is adapted to manage service 

10 in a script database of said application server means, 

which script database is adapted to store master copies of 
service scripts, wherein said managing functionality 
comprises at least one of the following functionalities: 
create, receive, test, check, validate, distribute and 

15 modify. 

According to further technical solutions 

- said script management functional entity is 
exclusively accessible by the operator of said 

20 communication network; 

- said script management functional entity is adapted 
to manage scripts to be stored and/or already stored; 

- said script database is connected to said service 
portal and to a secondary storage means for service scripts 

25 of said call state control functional entity; 

- said call state control functional entity further 
comprises a serving profile database, and said subscriber 
information register means comprises at least a subscriber 
profile database, and wherein said connection between said 

30 subscriber information register means and said call state 
control functional entity is established between the 
respective databases thereof; 

- said service portal is connectable via an access 
path to a terminal equipment; 



35 
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- said terminal is a wireless user equipment and said 
access path is established via a mobile communications 
network^ such as a GPRS network; 

5 - said terminal is a workstation and said access path 

is established via the internet; 

- a communication originates from or terminates at a 
terminal equipment, said terminal being connected to said 
call state control functional entity via an access network; 

10 - said terminal equipment is operated based on the 

internet protocol. 

According to the present invention, the above objects and 
aims are, for example, also fulfilled by 
15 a terminal equipment, said terminal comprising a 

functional entity which is adapted to enable the user of 
said terminal to manage service scripts, said managing 
comprising at least one of the following functions: create, 
test, distribute and modify service scripts. 

20 

According to further technical solutions 

- said terminal further comprising a memory for 
storing the service scripts created or modified by the user 
at the terminal; 

25 - said terminal is adapted to store the created or 

modified service scripts in a storage location of a 
communication network, to which network said terminal is 
registered; 

- said terminal is adapted to store the created or 
30 modified service scripts in a buffer memory of the call 

state control functional entity of said network, in case 
said script is valid for only one communication connection; 

- said terminal is adapted to store the created or 
modified service scripts in a subscriber profile database 

35 of a subscriber information register means of said network. 
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in case said script is valid for at least one coimnunication 
connection, 

- said terminal is adapted to store the created or 
modified service scripts in the application server of a 
5 home subscriber server of said network, in case said script 
is valid for at least one communication connections- 



It is to be noted that it is also conceivable to achieve 
the above objects and aims by a method according to which 

10 the user creates the services (service scripts) using an 
external functionality (not forming part of the CSCF, HSS, 
APSE, terminal) , which functionality offers a flexible user 
interface for service script creation and testing. The user 
defines the service using the external functionality and 

15 the functionality, as a result, provides a corresponding 
service script at its output (e.g. a CPL script) . The 
service script may then be transmitted either to the 
application server via the service portal or to the 
terminal of the user. 

20 

According to the present invention, the above objects and 
aims are, for example, also fulfilled by 

a communication system comprising a communication 
network as set out above and at least one terminal as set 
25 out above. 

According to the present invention, the above objects and 
aims are, for example, also fulfilled by 

a method of handling service scripts within a 
30 communication network, said method comprising the steps of 
creating service scripts by the network operator using a 
script management functional entity, and storing said 
service scripts in a script database adapted to store 
master copies of service scripts. 



35 
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According to further technical solutions: 

- the method comprises the steps of: loading, upon 
request of a respective user to manage his profiles, a copy 
of the master copies of the scripts from said script 

5 database and a copy of currently set scripts for said 
respective user from a subscriber profile database, to a 
service portal, providing a user interface according to 
currently set script settings at said service portal, 
selecting a loaded service script for changing the current 
10 setting of the profile, and storing an update of the set 
script settings in said subscriber profile database; 

- the method comprises the steps of: providing a user 
interface in the service portal to receive user originated 
scripts for storage in the application server; 

15 - currently set scripts for said respective user in 

said subscriber profile data base are network originated 
scripts created in the network by the network operator or 
user originated scripts created by the user of a terminal 
at the terminal, or created by a user using an external 

20 functionality dedicated for service script creation; 

- said subscriber profile database contains, for each 
script selected by a user, a script key as a pointer to the 
script logic of said script stored in said script database 
and script data unique to the respective user; 

25 - said script key is represented as a bit vector, with 

one bit of said bit vector representing the type of a 
service and the remaining bits of said bit vector represent 
features of said type of service; 

- said method further comprises the steps of: 

30 forwarding said script keys and script data contained in 
said subscriber profile database to a serving profile 
database of a call state control functional entity, 
checking that for the received script key a corresponding 
script is contained in a secondary storage means for 

35 service scripts of said call state control functional 
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entity, fetching the corresponding script logic from the 
secondary memory means upon occurrence of a script 
execution event; 

- each script key addresses a script logic fragment as 
5 a corresponding script, and the method further comprises 

the steps of composing a script to be executed from the 
script fragments addressed by the script keys, and 
executing the script logic of the composed script with the 
user specific script data. 

10 

Also, the present invention is directed to 

a method of handling service scripts within a communication 
network, said method comprising the step of composing 
service scripts within the network based on information 
15 from a subscriber data register. 

According to further technical solutions, 

- the service scripts are executed in call processing 
servers; 

20 - the information from said subscriber data register 

comprises features assigned to a subscriber and at least 
one service script is composed using the information on the 
said features; 

- the said features assigned to a subscriber are 
25 mapped to code skeletons; 

- the information from the said subscriber data 
register comprises also at least one parameter associated 
with these features; 

- the subscriber data register is inquired by the call 
30 processing servers in the network to enable the composing 

of the service scripts; 

- said call processing servers are equipped to send 
service scripts to other call processing servers to provide 
the overall service for a given subscriber; 
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-the call processing servers are equipped to request 
the deletion of said service scripts in other call 
processing servers ; 

- the call processing servers forward the information 
5 from the subscriber data register to an entity in 

association with the call processing server which composes 
the service scripts; 

- said entity in association with the call processing 
server is a service execution environment. 

10 

Also, the present invention is directed to 

a computer system comprising an execution environment 
for running an application for handling service scripts 
within a communication network operated according to the 
15 internet protocol according to the above method steps; and 
to 

a computer program product, loadable into the memory 
of a digital computer and comprising software code portions 
for performing the above method steps. 

20 

Accordingly, the present invention provides an architecture 
and a basic handling scenario which describes how 

• scripts are created and stored 

• scripts are provisioned for a user 

25 • scripts are distributed in a all-IP core network 

• scripts are executed during call processing. 

BRIEF DESCRIPTION OF THE DRAWINGS 

30 The present invention and its features and advantages will 
become more fully apparent when referring to the detailed 
description of the accompanying drawings, in which 

Fig. 1 illustrates a basic network architecture of an all-- 
35 IP communication network according to the present invention 
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and adapted to the script handling scenarios according to 
the present invention, and 

Fig. 2 illustrates a basic signaling scenario in connection 
5 with the composition of a script. 

DETAILED DESCRIPTION OF THE DRAWING 

Subsequently, firstly, the architecture of the 
10 communication network as illustrated in Fig. 1 is 

described, before secondly the script handling scenarios 
within said network architecture are explained - 

I. Communication network architecture of the IP based 
15 communication network 

Fig. 1 illustrates an explanatory view of the communication 
network architecture. It is to be noted that the drawings 
illustrate only those parts of the communication network 
20 which are essential in connection with the present g38 

invention and, for simplicity of drawing and explanation, 
that the illustrated number of respective parts is reduced 
to a minimum number. 

25 The illustrated communication network used as and example 
is assumed to be operated according to the internet 
protocol (IP) and thus constitutes a so-called all-IP 
network. Basically, said network comprises at least an 
application server means 1, a home subscriber server means 

30 6 as a subscriber information register, a call state 

control functional entity 1, and a service portal 2. Said 
application server means 1 is connected to said service 
portal 2 and to said call state control functional entity 
7, said service portal 2 is further connected to said home 

35 subscriber server means 6, and said home subscriber server 
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means 6 is further connected to said call state control 
functional entity 7. 

Note that the service portal 2 represents a service portal 
5 functionality. Although the service portal is illustrated 
as being separately provided from the application server 
APSE, it is of course, also possible that the service 
portal functionality is included in the application server. 
However, for explanation purposes, the description 
10 addresses to the service portal as a separate 
functionality . 

Said application server means 1 comprises a script 
management functional entity lA. Said script management 

15 functional entity lA is exclusively accessible by the 

operator of said communication network and is adapted to 
create, receive, check/validate, test, distribute and/or 
modify service scripts to be stored and/or already stored 
in a script database IB of said application server means !• 

20 Said script database IB is adapted to store master copies 
of service scripts, which can only be read by the call 
state control functional entity 7 and/or the service portal 
2. A writing of service scripts to the script database IB 
is only possible from the script management functional 

25 entity lA. The expression master copy of a script is 

intended to mean the script logic in the sense of a set of 
executable instructions without the individual data to be 
processed (the individual data depend for example on a 
specific user/terminal and or conditions prevailing in the 

30 network) or the script logic including the data for the 
script (both options are possible) . 

More particularly, said script database IB is connected to 
said service portal 2 and to a secondary storage means 7A 
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for service scripts of said call state control functional 
entity 7, 

With regard to said call state control functional entity 1, 
5 this entity further comprises a serving profile database 
7B, and said home subscriber server means 6 comprises at 
least a subscriber profile database 6A, Said connection 
between said home subscriber server means 6 and said call 
state control functional entity 7 is established between 
10 the respective databases 6A, 7B thereof. Also, the 
connection from said service portal 2 to said home 
subscriber server 6 is actually established from the 
service portal 2 to the subscriber profile database 6A of 
said home subscriber server 6. 

15 

Additionally, said service portal 2 is connectable via an 
access path 3, 4a, 4b to a terminal equipment 5a which is 
operated based on the internet protocol. In the illustrated 
example as shown in Fig. 1, said terminal 5a is a wireless 

20 user equipment (3G__UE) and said access path is established 
via an IP network 3, a mobile . communications network, for 
example a GPRS core network constituted by a serving GPRS 
support node (SGSN) 4b and a gateway GPRS support node 
(GGSN) 4a, and a radio access network (not shown) . However, 

25 alternatively and not shown in Fig. 1, said terminal 5a can 
be a workstation and said access path may be established 
via the internet (i.e. without the need to use a GPRS 
network) . 

30 In the illustrated communication network, a communication 
originates from or terminates at a terminal equipment 5b , 
said terminal being connected to said call state control 
functional entity 7 via an access network (e.g. a radio 
access network, not shown) . 



35 
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Note that although terminals 5a and 5b are shown in Fig. 1, 
these terminals may be identical. That is^ a terminal 5b 
used for communication via said communication network may 
be adapted to access the service portal 2 (situation 
5 illustrated using terminal 5a) for modification of service 
profiles defined for said terminal by respective service 
scripts. 

The terminal comprises a functional entity (not shown) 

10 which is adapted to enable the user of said terminal to 

create, test, distribute and/or modify service scripts. In 
so far, this functional entity at the terminal side is 
similar to the script management functionality lA of the 
application server 1, while the provided functionality for 

15 the scripts at the terminal side is mostly less powerful 
(e.g. only a restricted set of script language commands is 
available for the user at the terminal) . Also, the terminal 
further comprises a memory for storing the service scripts 
created or modified by the user at the terminal. 

20 Irrespective of whether the terminal is provided with a 
local memory for storing the scripts created at the 
terminal, the terminal is adapted to store the created or 
modified service scripts in a storage location of a 
communication network operated according to the internet 

25 protocol, to which network said terminal is registered. 

For example, the terminal is adapted to store the created 
or modified service scripts in a buffer memory (not shown) 
of the call state control functional entity 7 of said 

30 network, in case said script is valid for only one 

communication connection. Alternatively, the terminal is 
adapted to store the created or modified service scripts in 
a subscriber profile database 6A of a home subscriber 
server 6 of said network, in case said script is valid for 

35 at least one communication connection. In addition, the 
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terminal can store the created or modified scripts (via the 
service portal 2) also in the script database IB of an 
application server 1, in case said script is valid for at 
least one communication connection. 

Note also that scripts can be created with an external 
functionality which is dedicated to this purpose, and that 
also such externally created scripts may be stored in the 
application server via the service portal. 

The communication network as briefly described above in 
combination with at least one terminal as briefly described 
above constitutes a communication system. 



15 II. Script handling scenarios 

Subsequently, script handling scenarios within said network 
architecture and the communication system are explained. 



20 It is to be noted that scripts may be created either by the 
operator in the network or by the user in the terminal ( or 
using an external functionality dedicated for script 
creation. In the following, scripts created in the network 
(i.e. by the network operator) ^are referred to as "network 

25 originated scripts" and scripts created by the user are 
referred to as "user originated scripts". 

II. 1. Network originated script creation and storage 

30 For a communication environment, access to network 

resources should be made in a secure, controlled manner- 
This means that an essential part of script usage in a all- 
IP communication environment (network) resides in ensuring 
that script execution does neither hazard nor harm normal 

35 call handling. 
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One way to assure this is to allow only the operator to use 
powerful script languages (such as for example CGI or SIP 
Servlets) freely. The user may then select a script 
5 template which he desires to use from the scripts already 
made by the network operator. Also, a user could be allowed 
to combine "script components" provided by the network 
operator and thus create a script from those components. 
This means that functional elements taking care of script 

10 creation, testing and storage are needed by the operator in 
the network. These functional elements could be part of an 
application server (APSE) 1 as described in figure 1, where 
they are denoted as script management functional entity 
(SM) lA adapted to create, test, distribute and/or modify 

15 service scripts to be stored and/or already stored in a 

script database (SCRIPT DB) IB for storing the master copy 
of script. 

II. 2. Network originated script provisioning for a user 

20 

In an all-IP network it is desirable that user interfaces 
for service provisioning should be more powerful and user- 
friendly than currently existing ones. 

25 One possible scenario is that the service provisioning and 
service user management in general is done through a 
service portal (denoted by numeral 2 in Fig. 1), e.g. a web 
server offering tools and interfaces to the user enabling 
him to manage his service profile or profiles. 

30 

This portal could be accessed with a wireless terminal, 
which can be, for example a user equipment conforming to so 
called third generation communications standards, for 
instance UMTS standards created by 3GPP, via an access path 
35 constituted by a radio access network, for instance a GPRS 



wo 02/19732 



PCT/EPOO/08591 



- 17 - 

access network, an GSM EDGE access network, a CDMA/WCDMA 
access network, an IP access network or any other radio 
access network without consulting the control plane (CSCF) 
at all (this means that the access to the service portal is 
5 a pure data connection, with no speech required) . Another 
possibility (not shown in Fig. 1) is to access the portal 
with a work station via internet web browsing. 

Of course, authorization of users via, for example, a 
10 username and password is needed in order to assure 

consistent updating of user profiles for an all-IP network 
user. However, these mechanisms are not explained here, as 
they are not crucial for the present invention. Rather it 
is assumed that "required authorization issues are taken 
15 care of". The service portal and access from an IP Terminal 
(IPTE) 5a is shown in Figure 1. 

The service portal 2 has an interface towards the script 
database IB of the application server (APSE) 1 in order to 

20 find out what kind of scripts or script templates may be 

selected by the user. Furthermore, the service portal 2 has 
an interface towards the subscriber database HSS (Home 
Subscriber Server) also denoted by numeral 6, which 
contains the all-IP user profile information (including 

25 list of provisioned scripts and perhaps user's privileges 
for script usage) in a subscriber profile database 6A. 

Now, when the user wants to provision new scripts or modify 
existing scripts, the portal 2 requests the HSS 6 (i.e. the 

30 subscriber profile database 6A) for all-IP user profiles 

and also requests the script database IB of the application 
server 1 for available scripts. Next, the service portal 2 
provides the user terminal 5a the user interface according 
to current profile and script information. A subsequent 

35 user interaction between the IPTE and portal then proceeds 
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until the desired functionality is given from the terminal 
5a to the portal 2. If the user profile is changed (new 
scripts provisioned and/or old scripts changed) , the portal 
2 sends a user profile update request with required script 
5 information to the HSS 6, more precisely, to the subscriber 
profile database 6A thereof. The HSS 6 (subscriber profile 
database 6A) then updates the all-IP user profile. 

II. 3. Network originated script distribution over the all- 
10 IP network elements 

The master copy of the script (script logic) is kept in the 
script database IB in the application server 1 (APSE) . The 
script management (SM) functional element lA attached to 

15 the script database IB provides for script creation, 
modification and also script distribution. The script 
management functional element lA possesses information of 
the all-IP network elements to which read-only copies of 
the script logic must be distributed. The distribution may 

20 be effected for all scripts to all elements, or the scripts 
may be grouped for distribution purposes. Note that only 
the script logic (executable instructions without the data 
as such to be processed) needs to be stored in the script 
database IB. Script data (the data actually to be processed 

25 by the scripts) may for example be user specific, and it 
could be provided by the user profile in HSS. However, in 
some cases it may be useful to include also the data for 
the script inside the script logic. Thus, the separation of 
the logic and data is optional. 

30 

The user profile stored in home subscriber server 6 (HSS) 
contains information of all scripts provisioned for a given 
user. This information is stored with an identification of 
a script (script key as a pointer to the script logic of 
35 said script stored in said script database IB) , whereas the 
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script (script logic) itself is stored in the script 
database IB. 

A user profile may also contain (but may also exclude) 
5 script specific data, which may either have a default value 
or a value received from the service portal (possibly given 
by the user via the terminal 5a during an intercfction with 
the service portal 2) . This data (as the data to be 
processed) is needed when the script is executed. The home 

10 subscriber server 6 (HSS) delivers the user profile 
(including the script key and the data needed by the 
script) to a serving profile database 7B (SPD) attached to 
the call state control functional element 7 (CSCF) to which 
the user is currently registered. Note that the script data 

15 may have an absolute data value or possibly a reference to 
a logical system "variable" (e.g. expression "voice_mail") , 
which may be translated during script execution. When the 
serving profile database 73 (SPD) receives the user 
profile, it may check whether or not the scripts found from 

20 the user profile (identified by the script key) can be 

found from the local database 7A (a secondary storage means 
for service scripts, i.e. for script logic) of the call 
state control functional element 7 (CSCF) . 

25 If the script identified by the script key in the user 
profile is not found in the secondary storage for script 
logic 7A, the serving profile database 78 (SPD) may request 
the secondary storage 7A to start a script request towards 
the script database IB in the application server 1 (APSE) . 

30 If no script is fount from the script database IB either, 
the serving profile database 7B (SPD) may either discard 
the respective script or may start error handling with the 
home subscriber server 6 (HSS) . 
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11,4, Network originated script execution 

The user profile includes information of scripts 
5 provisioned for the user. When the user makes a call 

attempt (originating call or communication) or when a call 
is placed towards the user (terminating call), the user 
profile is fetched either from the serving profile database 
7B (SPD) (in case of originating calls) or from the 
10 subscriber profile database 6A of the home subscriber 

server 6 (HSS) (in case of terminating calls) to the call 
state control functional element 7. 

The scripts found from the user profile (i.e. those scripts 
15 to which script keys in the user profile are pointing) are 
armed according to script specific conditions. The script 
specific conditions are provided either by user profile 
data or by the script logic contents (the script logic 
stored in the secondary database 7A may include some script 
20 execution conditions, if required) . The armed scripts also 
specify (via script specific conditions) the event whose 
occurrence causes the execution of the script. The call 
handling of the call state control functional element 7 
(CSCF) must monitor those script events and start the 
25 script if and when required. The execution event of a 
script corresponds with the detection point of an armed 
trigger in an intelligent network. 

When the execution event of a script is met, the script 
30 logic is fetched (if not fetched during script arming) from 
the secondary storage 7A using the script key. The script 
logic and the script specific data (data is received from 
user profile or possibly from script logic contents) is 
given to a functional entity handling service requests in 
35 the call state control functional entity 7. This entity 
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either directly starts the local script execution or 
forwards the request towards a functional entity which 
contains a script execution machinery. The- call handling 
instructions are provided from the execution machinery to 
5 the call handling entities internally, 

II. 5. User originated script creation 

The basic .characteristics of the scripts are the same for 
10 scripts originated from the network or from the user. The 
following description therefore covers mainly the 
differences therebetween • 

The user may create scripts either within the terminal 5a, 
15 5b or using some external functionality (application run on 
a workstation, for example) dedicated for the purpose. 
Since the user himself has control over the script 
creation, somehow it must be secured that created scripts 
do not misbehave in the network, where they are executed. 

20 

There are several approaches to guarantee this kind of 
security: 

• Use of a suitable script language, which allows only a 
restricted set of available instructions for controlling 

25 the call handling. CPL is one example of such a language. 

• Restricting the allowed instructions during script 
execution in network, i.e. discard or ignore misbehaving 
parts of the terminal originated scripts. 

• Checking and validating the scripts when they are 
30 uploaded to the network. 

• Configuring the user interface available in the terminal 
for script creation in a way so that illegal instructions 
cannot be put into the scripts (this does not work for the 
external functionality for script creation as it is not 

35 necessarily part of the network domain) . 
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II. 6. User originated script storage, script created in the 
terminal 5a, 5b 

5 When the user creates the scripts in the terminal (5a, 5b), 
the scripts can be stored either in the terminal (5a, 5b) 
itself or the network to which the terminal is registered. 

If the master copy of the script is saved in the terminal 
10 (5a, 5b) , the script may be uploaded to the network for 
being executed at any time. Furthermore, if the script is 
executed in the network immediately after uploading, it 
needs not to be saved at the network at all. 

15 However, if the script conditions prevent immediate 
execution of the script, the script must be, at least 
temporarily, saved in the network (although the master copy 
is in the terminal (5a, 5b) ) . 

20 The master copy of a script created within the terminal may 
also be stored in the network. This is handy especially for 
scripts that are to be used permanently or for more than 
one call. In general, scripts that are to be used for at 
least one call can be stored in the network. The master 

25 copy of the script can be stored in the network either in 
the application server 1 (APSE) or the home subscriber 
server 6 (HSS) . 

In case the master copy of the script is stored in the 
30 Application Server, it is loaded there either directly or 
via the Service Portal (the Service Portal may offer a user 
interface for script uploading) . When a script is loaded 
from the terminal, the application server needs to check 
and validate the script before adding it to the script 
35 database IB. Some identification can be put to the stored 
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script in order to know that the script originates from the 
user/terminal. Note that it is prefe.rably to store the 
script to the Application Server, because this allows the 
network to handle the script (after checking and 
5 validation) , at least regarding to script execution, 

distribution, provisioning and activation, in the same way 
as the scripts created by the network operator h'imself . 

II. 7 User originated script storage, script created with 
10 external functionality 

If the user creates a script (which is to be executed in 
the network) using some external dedicated functionality 
(application and/or software), the user may be provided 

15 with a flexible and understandable high level user 

interface for service creation and testing. The external 
functionality creates the script according to a description 
given by the user through the functionality's user 
interface- Thus the burden to be able to create e.g. CPL is 

20 left for the external functionality. 

The created script is either downloaded from the external 
software to the terminal (5a, 5b) or the external 
functionality (software) may have a connection to the 

25 Application Server 1 for service script uploading either 

through the Service Portal 2 or directly to the Application 
Server. In case the script is downloaded to the terminal, 
it is further handled as if it was created in the terminal. 
In case uploading is done to the Application Server 

30 (possibly via the Service Portal) the Application Server / 
Service Portal needs to take care of the authentication and 
authorization of the user trying to upload scripts and 
check/validate the script to be uploaded to prevent from 
malicious or incorrect script storage. 



35 
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11,8 User originated script provisioning 

The script provisioning is exactly the same as with network 
originated scripts if the master copy of script is stored 
5 in the application server 1. If the master copy is stored 
in the terminal, provisioning is not needed, since the 
script is uploaded to the network for execution by the 
terminal . 

10 II- 9 User originated script execution 

Script execution is basically the same as with network 
originated scripts: the provisioned scripts are executed 
when the script specific conditions are fulfilled and when 

15 the event which triggers the execution of the script is 

encountered. Note that the execution conditions may also be 
provided call specifically: for example it is possible that . 
a script execution condition relates to a setup message 
data: the script is executed only when a certain field is 

20 recognized in e.g. SIP Invite message body part. 

As described above, call processing language scripts can be 
inserted to the call processing servers from various 
sources. However, a problem with the method according to 

25 the current CPL specifications is that the CPL scripts are 
treated as monolithic XML-documents. This means that the 
whole document comprising the script must be transmitted 
between network elements in completeness. According to RFC 
2824, this takes place at network registration. This means 

30 that the script is uploaded, for instance, as an embedded 
content within the SIP registration message. This script 
may have been composed using authoring tools within the 
user equipment such as an IP telephony terminal. 
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Similarly, it is under the responsibility of the user or 
network administration to upload the needed CPL scripts to 
the different network elements. It is under the 
responsibility of the user to know the servers to which the 
5 scripts have been uploaded - 



Furthermore, general reference has been made to "a script 
key as a pointer to stored script logic. According to a 
further aspect of the present invention, scripts to be 

10 executed are composed based on script logic addressed 

(pointed to) by a respective script key. In particular, a 
script key is represented as a bit vector, with one bit of 
said bit vector representing the type of a service and the 
remaining bits of said bit vector represent features of 

15 said type of service. Thus, each script key addresses a 
script logic fragment as a corresponding script, and a 
script to be executed is composed from the script fragments 
addressed by the script keys, and the script logic of the 
composed script is thereafter executed with the user 

20 specific script data. 

Stated in other words, the starting point of this aspect of 
the invention is that the script (for example, a CPL 
script) is composed at the 0-CSCF (originating call state 

25 control functional element in case of a network comprising 
plural call state control functional elements due to its 
size), and not at the end user terminal, (as hitherto usual 
in connection with SIP) • The idea of this aspect of the 
invention is to define in the home subscriber server's 

30 (HSS) registers (i.e. in its database) bit vectors that 
represent the provisioned services and features for e.g. 
outgoing calls. The bits represent the status of a service. 
For each service represented in the vector, there is a code 
fragment in the O-CSCF representing the service (for 

35 example, in the secondary storage for script logic 7 A, as 
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shown in Fig. 1) . The CPL script to the outgoing invite 
method is then composed from the code fragments in 
accordance with the bits on in the bit vector. 
Alternatively, if the interaction of the services is not 
5 sequential, a set of bits is mapped to the code fragment. A 
whole CPL script may consist of both fragments that can be 
appended sequentially and fragments which have been 
selected depending on a combination of service bits. 
Further, the CPL script may contain a slot for user 
10 provided fragments. 

Thus, SIP CPL scripts are encapsulated into SIP invite 
methods in a large IP telephony network. Thereby, some 
signaling is saved, and the CPL script composition process 
15 is controlled by the operator. 

To set out the above further aspect of the present 
invention in more detail, reference is made to Fig. 2. 

20 Fig. 2 illustrates a basic signaling scenario in connection 
with the composition of a script. Namely, the network 
operator provides within call processing servers a 
functionality to automatically compose CPL scripts from 
feature bit vectors. 

25 

Advantageously, this greatly reduces the burden on the end- 
user and the network operator, because CPL scripts causing 
unexpected behavior due to being written or configured by 
inexperienced end users do not have to be debugged 

30 separately. Similarly, it can be envisioned, that as the 
CPL script language is extended over the time, that the 
size of the CPL scripts to be uploaded to the network 
elements grows. This has significance in the case of 
wireless terminals, so that with the present aspect of the 

35 invention being implemented, the network bandwidth is not 
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consumed by transmitting big XML-documents over the air. at 
network registration. 

The idea of the present invention is to define for the call 
5 processing server only a feature set and its parameters 
which identifies the structure and the content of the 
needed call processing language script. 



This means that^ for instance, from the home subscriber 

10 server HSS at network registration or location updating, 
there is loaded to the CPS (call processing server) as a 
network element which comprises the call state control 
functionality CSCF, a feature vector describing the aims of 
the CPL script. The feature vector bits could define, for 

15 instance, call barring features, call rerouting features 
and user notification features (e.g. E-mail on each missed 
or forwarded calls. The interpretation of the feature 
vectors is based on HSS and CPS mutual agreement. Thus when 
for example subscriber data is loaded from the HSS or an 

20 equivalent service register to the CPS, the CPS inspects 

the feature vector associated with user data. Similarly, it 
inspects the parameters included also in the message in 
addition to the feature vectors. A parameter or a set of 
parameters is associated a given feature vector. The 

25 parameters can be opaque with respect to the CPS. 



According to the feature vector, the CPS selects the most 
appropriate CPL skeleton and inserts the parameters to the 
places in the skeleton as specified by the vector specific 
30 logic. 

It should be noted that the HSS or registry from which the 
feature vectors are extracted can be any subscriber data 
register storing information such as e.g. location or 
35 service data relating to subscribers. Examples of such 
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subscriber data registers are e.g. the HSS of UMTS, general 
SIP location registers, DHCP (Dynamic Host Configuration 
Protocol) servers and LDAP/X.500 directory servers. The 
general SIP location registers store information on user 
whereabouts and they can be inquired for routing 
information. The DHCP servers and LDAP/X.500 servers can be 
used e.g. in small ■ corporate networks to download 
subscriber information to the SIP servers currently serving 
a subscriber. 

In a modification of this aspect of the invention, the 
feature vector is interpreted so that each element 
represents the presence or absence of a feature- Thus each 
bit position in the bit vector has fixed meaning. 

In an another modification of the invention, the feature 
vector elements represent feature identifiers, which point 
to a certain feature and possible to certain GPL script 
code skeletons, 

In an embodiment of the invention the inspection of the 
feature vectors and the composing of the CPL script is 
performed in a service execution environment (SLEE) within 
the CPS or associated with it via a signaling interface 
such as an IN interface {e.g. based on CAMEL 
specifications) . The service execution environment could be 
e.g. a Java based virtual machine. The service execution 
environment is triggered at registration to the network, 
benefically from the CPS receiving the subscriber data and 
feature vector. The service execution environment obtains 
the subscriber data from the CPS. It constructs the CPL 
script to be stored to the CPS or to be sent at call set-up 
in the direction of the CPS of the called party. 
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The SLEE (service execution environment) can compose a 
multitude of CPL scripts when receiving the feature vectors 
and their parameters. There can be separate sub-feature 
vectors for CPL scripts to be sent to call processing 
5 servers of an outgoing call (called party direction) and 
separate scripts to be stored within the users current 
serving CPS (CPS corresponds to CSCF according t"o UMTS 
release 00 architecture) . 

10 In a modification of the invention, several SIP servers 
(CPS: call processing servers including a CSCF 
functionality) may participate in the call set-up process 
in the originating network or domain. This means that in 
the originating network the call set-up may pass several 

15 servers before it is finally routed to a different network. 
The CPL scripts formed on the basis of information received 
from the registry (e.g. HSS) , may be dedicated to different 
servers via which the call is set-up. Therefore, after the 
construction of the CPL scripts, some of the scripts may be 

20 distributed to different servers via which the call is 

known or anticipated to be set-up. This is possible e.g. so 
that to each of the constructed scripts there is associated 
and/or allocated the role or address of the server to which 
it must be installed. The CPS communicating with the 

25 registry knows the meaning of the roles and the servers 
acting in these roles for the subscriber. The CPS then 
knows to which servers it must send each script which is 
not dedicated for it. 

30 For instance, in the UMTS system (release 00 all-IP 

network) the call set-up first goes via a proxy server in 
the currently visited network, from where it is routed to 
an incoming call gateway server in the home network. The 
incoming call gateway server hides the structure of the 

35 home network from the visited network, so the contact point 
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is always the same for the proxy in the visited network, 
unless load sharing is performed between different servers. 
This means that the proxy server always sends the set-up to 
the same incoming call gateway server or servers (ICG) . The 
5 ICG then inquires e.g. the HSS with caller identification 
and determines the server (CPS, serving CSCF) currently 
serving the caller. 

Therefore, when the feature vector is received at the CPS 
10 interacting with the HSS, the analysis of the feature 

vector can result into the creation of several CPS scripts. 
These scripts may be dedicated to be distributed to 
different call processing servers. The dedication is either 
based on information contained in the feature vector or it 
15 is based on the decisions made in the CPS (e.g. further in 
the SLEE affiliated with the CPS) . 

For instance, some of the scripts may be dedicated to the 
proxy server in the visited network, some to the currently 

20 serving CPS, some to the incoming call gateway and some to 
be sent to the destinations of outgoing calls. When the 
script construction has been performed in the CPS 
communicating with the HSS, the CPS sends the scripts to 
the servers to which the scripts are dedicated. The CPS may 

25 have received the proxy server address and incoming call 
gateway address in the registration request. In load 
sharing cases, a copy of the same script may be sent to 
each of the servers between which the load is shared in the 
same roles (e.g. as incoming call gateway) . 

30 

The above presented enables, for instance, that the scripts 
sent to the proxy server in the visited network cause that 
certain call set-up requests are denied in the visited 
network before bothering the home network. The benefit of 
35 the solution is that the end-user doesn't know the servers 



wo 02/19732 



PCT/EPOO/08591 



- 31 - 

participating in call set-up. In some cases this has been 
hidden from the end-user. Therefore, it would not be 
possible for the end user to install the scripts separately 
to each possible server participating in call set-up as in 
5 the case of very simple IP telephony networks. 

The feature vectors in the HSS or registry are managed by 
some management application. The end-user contacts the 
management system of the operator via some graphical user 
interface. The end-user then makes some feature selections, 

10 activations and configurations (e.g. to activate call 
barring) . There may not be a one-to-one relationship 
between these features and the features in the feature 
vector. The user selections are interpreted by the 
management system, which manipulates the feature vectors in 

15 the HSS to be sent to the call processing servers later on. 
At the revocation of certain features, the HSS or registry 
notifies the current CPS of the new feature vector. This 
causes that the CPS sends a delete request to the other 
call processing servers to which the scripts that are no 

20 longer valid have been sent. When a user is considered 

unreachable by the network, the CPS making this observation 
performs implicit detach on the user and notifies all call 
processing servers which may have scripts for the user. For 
instance, the CPS making the observation may e.g. multicast 

25 or broadcast a delete request for the CPS scripts valid for 
the user to the network. This causes that no hanging old 
scripts may remain in the network. 

The CPL scripts that are attached to outgoing SIP invite 
30 requests (call set-up messages) can be used to update the 
version of the calling user associated CPL scripts in call 
processing servers in the direction of an outgoing call 
(CPS-U in Fig. 2). In that case they replace the version 
stored therein. Alternatively, these scripts can follow the 
35 SIP invite message (or similar call set-up message) all the 
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way to the called party final CPS (CPS-NO in Fig. 2) which 
contact- the called party user agent (UA, functionality 
implemented within IP terminal equipment TE) directly. 
These scripts can guide the call set-up all the way in the 
5 proxying and redirecting call processing servers and 
specify for example messages to be sent to various 
recipients in case of for example failure to set-up the 
call to any given specified party . 

10 Finally, it has to be noted that 

- an application server APSE could also be a service 
control point SCP, or any element responsible for giving 
controlling instructions for session management (call 
handling) , 

15 - a home subscriber server HSS as a subscriber information 
register could also be a home location register HLR of a 
GSM network/ or any other element having a subscriber 
information register, 

- a CSCF could be the call control function of a MSG or MSG 
20 Server, call control function of CPS (which actually is the 

CSCF) , call control function of a fixed network switch, or 
a SIP server responsible for routing the SIP messages 
between end points, 

- portal could also be accessed through WAP or SMS, 

25 - script can refer to any portable service logic PSL, i.e. 
any form of logic that can be transferred from its creation 
and management environment to some different element in the 
network for execution purposes. This element can be CPS, 
HSS, APSE, IPTE. Even the IN service logic designed to 

30 control the switch through traditional protocols such as 
INAP, CAMEL, WIN, OSA could be designed in such a way that 
instead of executing the instruction in the SCP, the logic 
could be moved to the switch and have the INAP, CAMEL, WIN, 
OSA as an interface in the switch. That is, a service 

35 script can be any portable service logic, not only the 
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script logics specified especially to be "scripts" (CPL, 
CGI, Servlets) • 

Accordingly, as has been described above, the present 
5 invention proposes a communication network, said network 
comprising at least an application server means, a 
subscriber information register means, a call state control 
functional entity, and a service portal, wherein said 
application server means is connected to said service 

10 portal and to said call state control functional entity, 
said service portal is further connected to said home 
subscriber server means, and said subscriber information 
register means is further connected to said call state 
control functional entity. In connection with the proposed 

15 network architecture, the present invention also proposes 
methods for handling service scripts within the network 
with regard to creation and storage of service scripts, 
provisioning the service scripts for a user, distribution 
of the scripts in the network and execution of the scripts 

20 during call processing. 



It should be understood that the above description and 
accompanying drawings are only intended to illustrate the 
present invention by way of example only. The preferred 
25 embodiments of the present invention may thus vary within 
the scope of the attached claims. 
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1. A communication network, said network comprising at 
least 

5 an application server means (1) , 

a subscriber information register means (6) , 
a call state control functional entity (7), and 
a service portal (2), wherein 

said application server means (1) is connected to said 
10 service portal (2) and to said call state control 
functional entity (7) , 

said service portal (2) is further connected to said 
subscriber information register means (6) , and 

said subscriber information register means (6) is 
15 further connected to said call state control functional 
entity (7), wherein said application server means (1) 
comprises 

a script management functional entity (lA) , and said script 
management functional entity (lA) is adapted to manage 

20 service in a script database (IB) of said application 

server means (1), which script database is adapted to store 
master copies of service scripts, wherein said managing 
functionality comprises at least one of the following 
functionalities : 

25 create, receive, test, check, validate, distribute and 
modif y- 

2. A communication network according to claim 1, wherein 
said script management functional entity (lA) is 

30 exclusively accessible by the operator of said 
communication network. 



3. A communication network according to claim 1, wherein 
said script management functional entity (lA) is adapted to 
35 manage scripts to be stored and/or already stored. 
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4. A communication network according to claim 1, wherein 
said script database (IB) is connected to said service 
portal (2) and to a secondary storage means (7A) for 

5 service scripts of said call state control functional 
entity (7) . 

5. A communication network according to claim 1, wherein 
said call state control functional entity (7) further 

10 comprises a serving profile database (7B), and said 

subscriber information register means (6) comprises at 
least a subscriber profile database (6A), and wherein said 
connection between said subscriber information register 
means (6) and said call state control functional entity (7) 

15 is established between the respective databases thereof. 

6. A communication network according to claim 1, wherein 
said service portal (2) is connectable via an access path 
(3, 4a, 4b) to a terminal equipment (Sa) . 

20 

7. A communication network according to claim 6, wherein 
said terminal (5a) is a wireless user equipment and said 
access path is established via a mobile communications 

25 network (4a, 4b) , such as a GPRS network, 

8. A communication network according to claim 6, wherein 
said terminal (5a) is a workstation and said access path is 
established via the internet, 

30 

9. A communication network according to claim 1, wherein a 
communication originates from or terminates at a terminal 
equipment (5b), said terminal being connected to said call 
state control functional entity (CSCF) via an access 

35 network- 
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10. A communication network according to claims 6 or 9, 
wherein said terminal equipment is operated based on the 
internet protocol. 

5 

11. A terminal equipment, said terminal comprising a 
functional entity which is adapted to enable the user of 
said terminal to manage service scripts, said managing 
comprising at least one of the following functions: create, 

10 test, distribute and modify service scripts. 

12. A terminal equipment according to claim 11, said 
terminal further comprising a memory for storing the 
service scripts created or modified by the user at the 

15 terminal . 

13. A terminal according to claim 11 or 12, which is 
adapted to store the created or modified service scripts in 
a storage location of a communication network, to which 

20 network said terminal is registered. 

14. A terminal according to claim 13, which is adapted to 
store the created or modified service scripts in a buffer 
memory of the call state control functional entity (7) of 

25 said network, in case said script is valid for only one 
communication connection. 

15. A terminal according to claim 13, which is adapted to 
store the created or modified service scripts in a 

30 subscriber profile database (6A) of a subscriber 

information register means (6) of said network, in case 
said script is valid for at least one communication 
connection. 
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16. A terminal according to claim 13, which is adapted to 
store the created or modified service scripts in the 
application server of a home subscriber server of said 
network, in case said script is valid for at least one 

5 communication connection, 

17. A communication system comprising a communication 
network according to any of claims 1 to 10 and at least one 
terminal according to any of claims 11 to 16. 

10 

18. A method of handling service scripts within a 
communication network, said method comprising ^the steps of 

creating service scripts by the network operator using 
a script management functional entity (SM) , and 
15 storing said service scripts in a script database (IB) 

adapted to store master copies of service scripts. 

19. A method of handling service scripts according to claim 
18, further comprising the steps of: 

20 loading, upon request of a respective user to manage 

his profiles, a copy of the master copies of the scripts 
from said script database (IB) and a copy of currently set 
scripts for said respective user from a subscriber profile 
database (6A) , to a service portal, 

25 providing a user interface according to currently set 

script settings at said service portal, 

selecting a loaded service script for changing the 
current setting of the profile, and 

storing an update of the set script settings in said 

30 subscriber profile database. 

20. A method of handling service scripts according to claim 
18, further comprising the step of: 
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providing a user interface in the service portal (2) 
to receive user originated scripts for storage in the 
application server (1, IB) . 



5 21. A method of handling service scripts according to claim 
19, wherein currently set scripts for said respective user 
in said subscriber profile data base {6A) are network 
originated scripts created in the network by the network 
operator or user originated scripts created by the user of 
10 a terminal at the terminal, or created by a user using an 
external functionality dedicated for service script 
creation. 



22. A method of handling service scripts according to claim 
15 17, wherein said subscriber profile database contains, for 

each script selected by a user, a script key as a pointer 
to the script logic of said script stored in said script 
database (IB) and script data unique to the respective 
user. 

20 

23. A method of handling service scripts according to claim 
22, wherein 

said script key is represented as a bit vector, with 
one bit of said bit vector representing the type of a 
25 service and the remaining bits of said bit vector represent 
features of said type of service. 

24. A method of handling service scripts according to claim 
22 or 23, further comprising the steps of: 

30 forwarding said script keys and script data contained 

in said subscriber profile database (6A) to a serving 
profile database (7B) of a call state control functional 
entity (7) , 

checking that for the received script key a 
35 corresponding script is contained in a secondary storage 
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means (7A) for service scripts of said call state control 
functional entity (7) , 

fetching the corresponding script logic from the 
secondary memory means (7A) upon occurrence of a script 
5 execution event. 



25. A method of handling service scripts according to claim 
24, wherein each script key addresses a script logic 
fragment as a corresponding script, and which method 

10 further comprises the steps of 

composing a script to be executed from the script 
fragments addressed by the script keys, and 

executing the script logic of the composed script with 
the user specific script data. 

15 

26. A method of handling service scripts within a 
communication network, said method comprising the step of: 

composing service scripts within the network based on 
information from a subscriber data register. 

20 

27. A method of handling service scripts according to claim 
26, wherein the service scripts are executed in call 
processing servers. 

25 28. A method of handling service scripts according to claim 
26, wherein the information from said subscriber data 
register comprises features assigned to a subscriber and at 
least one service script is composed using the information 
on the said features. 

30 

29. A method of handling service scripts according to claim 

28. wherein the said features assigned to a subscriber are 
mapped to code skeletons. 
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30. A method of handling service scripts according to claim 
28, wherein the information from the said subscriber data 
register comprises also at least one parameter associated 
with these features. 

5 

31. A method of handling service scripts according to claim 
26, wherein the subscriber data register is inquired by the 
call processing servers in the network to enable the 
composing of the service scripts. 

10 

32. A method of handling service scripts according to claim 
31, wherein said call processing servers are equipped to 
send service scripts to other call processing servers to 
provide the overall service for a given subscriber. 

15 

33. A method of handling service scripts according to claim 
32/ wherein the call processing servers are equipped to 
request the deletion of said service scripts in other call 
processing servers. 

20 

34. A method of handling service scripts according to claim 
28 or 31, wherein the call processing servers forward the 
information from the subscriber data register to an entity 
in association with the call processing server which 

25 composes the service scripts. 

35. A method of handling service scripts according to claim 
34, wherein said entity in association with the call 
processing server is a service execution environment 

30 (SLEE) . 

36. A computer system comprising an execution environment 
for running an application for handling service scripts 
within a communication network according to any of claims 

35 18 to 25 or 26 to 35. 



wo 02/19732 



PCT/EPOO/08591 



- 41 - 

37. A computer program product, loadable into the memory of 
a digital computer and comprising software code portions 
for performing the steps of any of claims 18 to 25 or 26 to 
5 35. 



wo 02/19732 



1/2 



PCT/EPOO/08591 




wo 02/19732 



2/2 



PCT/EPOO/08591 



CO 



CO 



CO 
H 
O 



CO 

o 



A 
I 
I 
I 
I 



01 
-rl 



I 



A 

I 
I 
I 
I 
I 
I 

M I 

5 1 

01 1 
•H I 

di I 
4). I 




U V 



I 

H 
O 

•rl 

& 



I 

CO 

u 



I 

+3 

Q) 



01 CO 

Ai 
H U 
H 

(d 

O 
>i 

:^ 

(D 

& 



I 
I 
I 
I 
t 

I (D 



O V 



in 



6* 
5 



a 

0 
•H 
43 

O 

. 45 
• w 

0 
0 



O I 

r-i CO 
0) Pi 
^ O 

0 

(H 4J 



•H 

u 

4» 

<D 



C 
O 
•H 
+> 
0 

S 

0 



I 

4> 
<D 



O 

I 



43 
43 

a 

(D 

^ " >; 
SJjg 

0) 

a -d 43 

O Q) 
d 

H 



0 o 



-H 

> 



« H 
QJ >t CO 



01 
0) 
53 

•H 
4> 

a 
o 
o 

I 

43 
<D 
01 



o 



■H 



A 
I 
I 
I 



H 1 
CO I 



INTERNATIONAL SEARCrf'.'iEPORT 



Int lal Application No 

P../wP 00/08591 



A. CLASSIFICATION OFSUBJECT MATTER , , 

IPC 7 H04Q3/00 H04L29/06 H04M7/00 



Aocordtngto International Patent Classification (IPC) or to botti national classification and (PC 



a RELDS SEARCHED 



Minimum documentation searched (classification system followed tiy dasaiflcation symbols) 

IPC 7 H04Q H04L H04M 



Oocumentatlon searched other than mbilmum documentation to the extent that such documents are Included in the fields searched 



Electronic data base consulted during the international search (name of data base end, where practfcai search terms used) 

EPO-Internal , WPI Data, PAJ, INSPEC 



C. DOCUtyiENTS CONSIDERED TO BE RELEVANT 



Category * Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



wo 00 42760 A (ERICSSON TELEFON AB L M) 
20 July 2000 (2000-07-20) 
page 4, line 14 -page 6, 11ne 22 
page 11, line 4 -page 14, line 7 

WO 99 20060 A (DSC TELECOM LP) 

22 April 1999 (1999-04-22) 

page 5, line 2 -page 13, line 27 

ROSENBERG J ET AL: "PROGRAMMING INTERNET 

TELEPHONY SERVICES" 

IEEE NETWORK, IEEE INC. NEW YORK, US, 

vol. 13, no. 3, May 1999 (1999-05), pages 

42-49, XP000870630 

ISSN: 0890-8044 

the whole document 

-/-- 



1-37 



1-37 



1-37 



S 



Further documents are listed in the continuation of box C. 



ID 



Patent family members are listed in annex. 



* Special categories of cited documents : 

*A' document defining the general state of the ait whteh Is not 

considered to be of particular ratevarce 
*E' earliar document but published on or after the International 

filing date 

•L' document which may throw doubts on prlortty cialm(s)or 
which is cited to establish the publication date of another 
c&ation or other special reason (as specified) 

'0* document refen'ing to an oral disclosure, use, exiilbltlon or 
other means 

"P* document published prior to the international flHng date but 
later than the priority date claimed 



'T* later document published after the International filing date 
or priority date and not in conflict with the application but 
died to understand the principle or thaoiy underlying the 
Invention 

'X' document of particular relevance; the claimed invention 
cannot tie considered novel or cannot be considered to 
Involve an inventive step when the document is taken aione 

'V document of particular relevance; the claimed Inventton 
cannot be considered to Invofve an inventive step when the 
document Is combined with one or more other such docu- 
ments, such combination being obvious to a person sidlied 
in the art. 

■&■ document member of the same patent family 



Date of the actual completion of the international search 



16 May 2001 



Date of maiUng of the intemationai search report 



23/05/2001 



Name and mailing address of the ISA 

European Patent Cnflce, P.a 5818 Patentlaan 2 
NL-22aO HV Ri]swi]k 
TeL (431-70) 340-204^ Tx. 31 651 epo nl. 
Fax: (+31-70) 340-3016 



Authorized oincer 



Chassatte, R 



INTERNATIONAL SEARCH REPORT i „ 1 

Inl onal Application No 

Pui/EP 00/08591 


C.(Conttnuation) DOCUMENTS CONSIDERED TO BE RELEVANT 


Calegoiy • 


Citation of document, with Indlcation.where appropriate, of ttie relevant passages 


Relevant to claim No. 


A 


WO 97 22209 A (LOW COLIM ; HEWLETT PACKARD 
CO (US)) 19 June 1997 (1997-06-19) 
page 16, line 13 -page 20, line 8 





INTERNATIONAL SEARCH REPORT 

ormfltlon on patent family members 


Int 3nal Application No 

Pti/tP 00/08591 


Patent document 
dted In search report 


Publication 
date 


Patent family 
member(s) 


Publication 
date 



wo 0042760 


A 


20- 


-07-2000 


AU 


2334400 A 


01-08-2000 










AU 


2334500 A 


01-08-2000 










WO 


0041499 A 


20-07-2000 


WO 9920060 


A 


22- 


-04-1999 


AU 


9514398 A 


03-05-1999 










EP 


1020088 A 


19-07-2000 


WO 9722209 


A 


19- 


-06-1997 


AU 


704503 


B 


22-04-1999 










AU 


1104097 


A 


03-07-1997 










AU 


704508 


B 


22-04-1999 










AU 


1104297 


A 


03-07-1997 










AU 


704385 


B 


22-04-1999 










AU 


1104697 


A 


03-07-1997 










AU 


704569 


B 


29-04-1999 










AU 


1181397 


A 


03-07-1997 










CA 


2238501 


A 


19-06-1997 










CA 


2239408 


A 


19-06-1997 










CA 


2239493 


A 


19-06-1997 










CA 


2239826 


A 


19-06-1997 










CN 


1208534 


A 


17-02-1999 










CN 


1208535 


A 


17-02-1999 










CN 


1208536 


A 


17-02-1999 










EP 


1059814 


A 


13-12-2000 










EP 


0867091 


A 


30-09-1998 










EP 


0867092 


A 


30-09-1998 










EP 


0867093 


A 


30-09-1998 










EP 


0867094 


A 


30-09-1998 










UO 


9722210 


A 


19-06-1997 










UO 


9722211 


A 


19-06-1997 










' WO 


9722212 


A 


19-06-1997 










JP 


2000516406 


T 


05-12-2000 










JP 


2000516407 


T 


05-12-2000 










JP 


2000516408 


T 


05-12-2000 










NO 


982510 


A 


05-08-1998 










NO 


982511 


A 


05-08-1998 










NO 


982512 


A 


05-08-1998 










NO 


982514 


A 


05-08-1998 










NZ 


324340 


A 


25-11-1998 










MZ 


323992 


A 


28-10-1998 










EP 


0792074 


A 


27-08-1997 










US 


5949871 


A 


07-09-1999 



